This is ready to review!

Or... not quite ready for review. The new tests are taking an extraordinarily long time on CI - over 30 seconds when they just take a few milliseconds locally! My best guess is that the Cesium3DTileset is either not ticking, or it's ticking much more slowly, and so the height queries are taking ages.

The test failures in UE 5.3 and 5.4 are caused by this previously-discovered problem:
#1219
If Actors don't tick, then terrain doesn't load. Not sure what best to do about this yet.

The problem mentioned above has been fixed, so this is ready to review.

This seems to work well! I'm still adding some comments but the results look great so far. In our 04_MAIN_CesiumSublevels level I tested putting a globe-anchored in every location, which involved querying against both Cesium World Terrain and Aerometrex Denver Photogrammetry. Both queries completed and resulted in accurate placement on each tileset -- nice!

Also tested what happens if you give the function a position that isn't on the tileset, and it correct returns false for the sample's success.

Here's the Blueprint I used if anyone wanted it for reference:
https://blueprintue.com/blueprint/t0mh0s4t/

I also noticed that the performance tests take between 6-10 seconds, is that expected? I thought it might have to do with the cache, but even with a warm cache it took around 5-6 seconds on my machine. Maybe I had too many browser tabs open 😛

I also noticed that the performance tests take between 6-10 seconds, is that expected?

That doesn't sound too far out of line. The tests are doing 400 height queries, spread out over a large enough area that it requires loading quite a few tiles, especially in the GP3DT case.

I think I've addressed everthing, this is ready for another look.

@kring the changes look good, but I'm still seeing the same behavior with the tileset not being valid. :(

I set the ion Asset ID of a tileset to be 0, which is not a valid tileset. I stepped through the code and found that pTileset is actually not null, so it's still attempting to resolve the height queries in the tileset's updateView. Then I think it's an issue with cesium-native. In particular, this line is never triggering:

    if (!this->_heightRequests.empty() && this->_pTilesetContentManager &&
        this->_pTilesetContentManager->getRootTileAvailableEvent().isReady()) {
      TilesetHeightRequest::failHeightRequests(
          this->_heightRequests,
          "Height requests could not complete because the tileset failed to "
          "load.");
    }

_heightRequests isn't empty, and _pTilesetContentManager isn't nullptr. But I guess that getRootTileAvailableEvent isn't being marked as ready. Is that expected? I guess if there's no root tile, then it doesn't make sense to have that event be ready, so maybe we should remove this check?

Other than that, this can be merged! If it can't be fixed before release, no worries, we can note it as a TODO issue in cesium-native.

@j9liu I believe asset ID 0, and also a blank URL, are a special case because we never even try to load a tileset in those states. Any other tileset failure should work as expected, I think. I can't quite decide if the behavior in the special case is a bug or a feature... Essentially it'll wait until those properties are set and then do the height query, rather than failing immediately.

Ah okay @kring . I was also trying other bogus asset IDs aside from 0 (like 2, which is a raster overlay), but I can see them falling into the same category of "we never load this tileset". These were just the easiest "failures" I could simulate, that's why I seem fixated on them 😛 If there's any other failures I should / could test, definitely let me know

Asset ID 2 should fail. If it's not, something is wrong. I'll check it out!